在 Sprint 中遇到產品發生問題要怎麼辦？

上一篇我們提到，已經上線的東西出現問題必需要修改，這就是上線產品的 Bug。這也可以分成兩個部分來討論，緊急跟不緊急。不緊急的部分代表我們不急著現在一定要修理，可以以後再修理，這部分我們就先不討論。

緊急的部分，代表我們馬上要處理，例如購物網站現在無法結帳，那就是很緊急的情況我們必需要馬上處理的。當然什麼是緊急情況，每個產品可能不同，自己可以有自己的定義。

當這種情況發生時，我們就要先放下手邊的工作立即處理。這時很可能就影響了我們原本 Sprint 的進度，如果發生太多次，或問題棘手需要多一點人一起處理時，有可能導致達不到 Sprint 的目標。這就是一個很嚴重的情形了。如果每個 Sprint 幾乎都這樣，那該怎麼辦？要怎麼解決問題？

解決問題的第一步，就是要承認問題的存在

首先我們必需承認我們目前的產品有問題，然後才能想辦法來解決問提。當然怎麼解決問題，問題的情況有很多，解決的方法更多，但我這邊想討論的是，如何減少團隊被這種突如其來的問題所困擾，導致 Sprint 受到影響。

問題就是會發生，我們就是要處理

現實的情況就是我們的產品目前存在一些缺陷，這些缺陷發生時我們必需要調派人力馬上處理。而調派人力去處理它就會影響我們原本的進度。

如果我們換一個角度想，問題就是會發生，我們就是要處理，那我是不是可以先派一個人在那邊等著，等問題來的時候就可以馬上處理。你也許會說，團隊的人手不夠，如果派一個人專門處理，只會讓進度更慢，而且老闆也不會同意有一個人在那邊等問題發生平常什麼都不做。

不要輕忽 context switch 所帶來的影響

我們先假設一個團隊有 5 個人好了，如果我們派一個人專門處理問題，這樣原本團隊的戰力就剩下 80%， 但你需要想想，如果按照原本的情況，有問題來時再派人力處理，這樣一來一往的 context switch 後，所剩下的團隊整體戰力，我想跟 80% 比起來不會多多少，甚至不到 80%。

Workaround 所帶來的影響

通常我們在處理線上問題的時候，往往不容易一開始就找到問題的根源，或是要修掉問題的根源需要花太多時間，所以常常會使用一些所謂的 Workaround。 使用 Workaround 來解決問題，本身並沒有太大的問題。問題在於太多的 Workaround 而不去解決原本的真正問題，會照成技術債越來越多，最後會把我們的系統拖垮。但是如果團隊有一個人專門在處理問題，有問題發生時他就處理，當問題沒有發生的時候他就可以研究如何徹底解決這些問題，以減少這些技術債。所以這一個人並不是沒有在做事的。